[RTL] ICCM XOR Infection#481
Conversation
nasahlpa
force-pushed
the
dev/nasahlpa/iccm_xor_infection
branch
3 times, most recently
from
a16b2dc to
b562402
Compare
|
Coverage report for this PR is available at https://chipsalliance.github.io/Cores-VeeR-EL2//html/dev/481/coverage_dashboard/all, documentation is available at https://chipsalliance.github.io/Cores-VeeR-EL2//html/dev/481/docs_rendered/html |
andreaskurth
left a comment
andreaskurth
left a comment
There was a problem hiding this comment.
Thanks @nasahlpa! I think this correctly and completely implements address infection into ICCM data. The documentation is updated consistently as well.
The added test confirms that the added feature doesn't break normal execution but it doesn't verify the countermeasure yet. Not a blocker for this commit, but should be tracked as follow-up with an issue, I think.
Previously, `el2_ifu_iccm_mem` exposed two different ICCM read signals: - `iccm_rd_data_ecc`: Data from ICCM containing ECC. This signal is used inside `el2_ifu_mem_ctrl` to detect ECC errors. - `iccm_rd_data`: Aligned data without the ECC. This signal is used for the actual instruction execution. As `el2_ifu_iccm_mem` is not within the DCLS domain, a fault injected into `iccm_rd_data` would not be detected, neither by DCLS nor by ECC. This commit moves `iccm_rd_data` into `el2_ifu_mem_ctrl`, which is within the lockstep domain. Signed-off-by: Pascal Nasahl <nasahlpa@lowrisc.org>
When enabled, before data is written into ICCM, the data is XORed with its write address. When the data is read back, this is removed by XORing the read address on the data. This creates a tie between write and read address. If read or write address would not match, the XOR in the read step would give garbled data, which is then detected by the ECC check. Signed-off-by: Pascal Nasahl <nasahlpa@lowrisc.org>
Signed-off-by: Pascal Nasahl <nasahlpa@lowrisc.org>
nasahlpa
force-pushed
the
dev/nasahlpa/iccm_xor_infection
branch
from
b562402 to
e55c0f1
Compare
|
Thanks for the review, Andreas. I have tracked the testing in issue #489. |
andreaskurth
left a comment
andreaskurth
left a comment
There was a problem hiding this comment.
Thanks @nasahlpa, this LGTM!
2 participants
When the optional build argument
iccm_addr_xoris set, the ICCM write word address is XORed into the data that gets stored into the ICCM. On a read, the ICCM read word address is XORed on the fetched data from ICCM. If both addresses match, the plain data is retrieved.If the read address does not match the write address, the address does not cancel. As after the read XOR the ECC check happens, the mismatch is detected by an ECC error. In addition, as the data is garbled, the instruction is corrupted as well.
This serves as an additional fault injection countermeasure.